Exchange Server 2003 : SMTP Protocol Configuration and Management - Managing SMTP Message Transfer Support

How SMTP Implements a Connection

When an Exchange Server 2003 host communicates with another host, it does so using standard SMTP commands and numerical reply codes over TCP port 25. This communication uses an asymmetric request-response protocol, which simply means that one host sends a command, waits for a reply, and then sends the next command. Suppose that an SMTP client (Host01) sends a message to an SMTP server (Server01). The procedure is as follows:

Common SMTP Commands

The SMTP commands define the mail transfer or the mail system function requested by the user. The commands consist of alphabetic character strings terminated by the carriage return/line feed character (<CRLF>). If a command code has parameters, then it is followed by a space character (<SP>), the parameters, and then <CRLF>. Table 1 lists the common SMTP commands. This list is not comprehensive. A full list of commands can be found in the RFCs.

Common SMTP Reply Codes

Table 2 lists the common SMTP reply codes. The commands are text strings, whereas the replies are numbers. However, reply codes 220 and 221 include the FQDN of the receiving host as a parameter. As before, this list is not comprehensive.

How ESMTP Implements a Connection

ESMTP uses the standard SMTP commands and response codes over TCP port 25 but also provides additional capabilities such as delivery notification. ESMTP communication can be made more secure by means of advanced messaging commands that support host authentication and encryption. If an ESMTP host initiates a session with a host that does not support the protocol, then it will use normal SMTP.

Windows 2000 and Windows 2003 operating systems support ESMTP by default. There are also ESMTP clients available for UNIX and Apple Macintosh operating systems:

Let us again suppose that an ESMTP client (Host01) sends a message to an SMTP server (Server01). The procedure is as follows:

Common ESMTP Commands

ESMTP uses the standard SMTP commands (with the exception of helo) and also uses some additional commands. Table 3 lists some common ESMTP commands. A more detailed list of ESMTP commands is available in RFC 1869. Further details are given in the additional RFCs listed in the table.

Testing an ESMTP Connection

The ehlo command may be used to test connectivity between your Exchange Server 2003 server and a remote SMTP host. If the remote host recognizes the command, then you can authenticate sending and receiving hosts and use encryption. You first establish a connection over TCP port 25 using the telnet utility. On establishing the connection, telnet will indicate whether the remote host supports ESMTP. However, this is not sufficient to indicate that an ESMTP connection can be established. It is possible, for example, that the recipient host is an Exchange server with the System Attendant service stopped. To test ESMTP connectivity, you must then issue the elho command. If you are testing the connection while logged on at another computer (which should be the case in a production network), then you need to follow the command with the FQDN of your server. If the remote host responds with a 250 reply, then it supports ESMTP commands. Figure 1 illustrates this technique.

You can use the same technique to test standard SMTP connectivity between your server and a remote host. In this case, you should use the helo command rather than the ehlo command.

SMTP Folders

SMTP uses three system folders to temporarily store messages in transit. By default, these folders are created on an Exchange Server 2003 server in C:\ProgramFiles\Exchsrvr\Mailroot\vsi 1. The folders are as follows:

• Pickup SMTP delivers any SMTP formatted messages that are placed in the Pickup folder. Exchange Server 2003 does not use this folder.

• Queue SMTP stores inbound SMTP messages in this folder when they are received. Internet Information Services (IIS) then processes these messages for delivery.

• Bad Mail SMTP stores undeliverable messages that cannot be returned to the sender in this folder.

If you want to change the location of these folders, you need to make the change in the configuration partition of Active Directory. Otherwise the changes will be overwritten. Use the Adsiedit.exe tool for this purpose.

Configuring DNS to Support SMTP

Having a well-designed DNS service is critical to the operation of an Exchange Server 2003 organization. In a production network, you should ensure that DNS does not constitute a single point of failure by the use of secondary DNS servers, Active Directory Integrated DNS, or both. When an SMTP host sends an e-mail message to another SMTP host, DNS resolves the SMTP domain name of the receiving host to its IP address. SMTP domain names and host addresses are held in DNS Mail Exchanger (MX) records.

Typically, an organization registers multiple MX records in DNS to provide fault tolerance if an SMTP host becomes unavailable. If the recipient SMTP host is unavailable, then the sending SMTP host retrieves all MX records for the receiving domain from DNS and resolves the lowest-preference SMTP host name to an IP address. If the SMTP host with the lowest preference is not available, the SMTP host with the second-lowest preference is used. When an available SMTP host’s IP address is resolved, an SMTP session is established with that host.

Exchange recipients can have a single SMTP address or multiple SMTP addresses. Exchange can segregate recipients into multiple virtual organizations, each with its own SMTP address space and domain name. You can configure DNS to support multiple Exchange servers within your organization and implement a single or multiple domain namespaces. Your DNS configuration also depends on how your Exchange organization is connected to the Internet and whether your DNS records are managed internally or by your Internet service provider (ISP).

MX Records for an Organization that Manages Its Own DNS

Table 4 shows how you could configure MX records if your organization manages its own DNS and has a single namespace. Host (A) records should exist for Server01, Server02, and Server03.

Tables 5 and 6 show how you could configure MX records if your organization manages its own DNS and has multiple namespaces. Host (A) records should exist for Server01 and Server02 in both the tailspintoys.com and nwtraders.com namespaces.

MX Records for an Organization Whose ISP Manages Its DNS

Table 7 shows how your ISP could configure MX records if your organization has a dial-up connection to the Internet and the ISP manages your organization’s DNS. Notice that the ISP’s smart hosts are in a load-sharing configuration and have equal preference. Host (A) records for Smarthost01 and Smarthost02 must exist in the ISP’s namespace.

Table 8 shows how your ISP could configure MX records if your organization has a permanent connection to the Internet and the ISP manages your organization’s DNS. In this configuration, messages will be delivered to the ISP’s smart hosts if the connection goes down, and you can retrieve them when the connection is re-established. Host (A) records for Smarthost01 and Smarthost02 must exist in the ISP’s namespace, as must a Host (A) record for server01.tailspintoys.com.

Configuring Internet Connectivity

If you want to change how messages flow in and out of your Exchange organization, you have several options that allow you to control and configure Internet connectivity. These include the following:

• Creating and configuring an additional SMTP virtual server and configuring an SMTP connector to use this virtual server as a bridgehead.

• Limiting the scope of the SMTP connector to the routing group.

• Configuring the credentials on the SMTP connector.

• Configuring the SMTP connector only to receive e-mail or only to send e-mail.

• Configuring Internet message formats and message delivery parameters.

Creating an Additional SMTP Virtual Server

You can use the default virtual server to configure control filters, relay restrictions, message formats, outbound security, and smart host options. However, if you want to control these items domain by domain, you should create an additional virtual server and then configure an SMTP connector to use the virtual server as a bridgehead server.

When you configure the virtual server in this way, the SMTP connector overrides any settings that the SMTP virtual server and SMTP connector share. You can, for example, create an SMTP connector with an address space for a specific e-mail domain and configure that connector to use a virtual server that does not have any filters configured. This setup can be used for sending messages across an extranet to one of your organization’s associate companies. You create and configure an SMTP connector later in this lesson.

Limiting the Scope of an SMTP Connector

You can limit the scope of an SMTP connector to a specific routing group. You would do this if you did not want messages from other routing groups to be delivered by the SMTP connector. However, if you want the SMTP connector to act as a backup to other similarly configured SMTP connectors in other routing groups, then you should accept the default scope setting, which is Entire Organization.

Configuring the Credentials on an SMTP Connector

You would configure the credentials on an SMTP connector if, for example, the connector is configured to deliver messages to a domain, and the SMTP server in that domain requires authentication. Configuring connector credentials does not affect the virtual server, which could, for example, be configured with no outbound security. Clients could then connect to other domains anonymously, while authentication is required to connect to the domain where it is specified.

Configuring an SMTP Connector Only to Receive E-Mail or Only to Send E-Mail

Suppose, for example, that your Exchange Server 2003 server cannot perform DNS lookups for Internet addresses, and you want to designate this server as your gateway to the Internet. In this case, you can configure an SMTP connector and then designate a bridgehead server for the connector to use. You also need to configure the connector scope, message routing, and address space.

Configuring Internet Message Formats and Message Delivery Parameters

Internet message formats enable you to configure the encoding, format, and type of messages (such as out-of-office or NDRs) that you send to a specific domain. The domain can then reference a specific destination, such as nwtraders.com. Alternatively, you can use a wildcard, for example *.edu, to reference a large group of destinations. You can define the message format for all SMTP domains or for specific domains.

Configuring SMTP Relays

Relaying occurs when one SMTP host forwards SMTP e-mail to another SMTP host without resolving the recipient addresses. You can use an SMTP connector to relay e-mail messages between Exchange Server 2003 and other SMTP-compatible messaging systems such as UNIX Sendmail (see www.sendmail.org) or to other SMTP hosts on the Internet. The bridgehead server or servers defined on SMTP connectors will relay e-mail messages directly to a smart host or to a remote server on which recipient addresses are stored.

There are six different ways to configure SMTP relays in Exchange Server 2003:

• Configuring an SMTP virtual server to use a smart host

• Configuring an SMTP virtual server to forward unresolved messages to a smart host

• Configuring an SMTP virtual server as a relay host

• Configuring an SMTP virtual server to limit the servers that can relay e-mail messages

• Configuring an SMTP connector to use a smart host

• Configuring the domains to which you want to relay messages

Configuring an SMTP Virtual Server to Use a Smart Host

An SMTP virtual server, by default, uses DNS to resolve the recipient’s SMTP address. You can instead configure the virtual servers in your organization to forward all outbound mail to a smart host. The virtual server does not then attempt to resolve the SMTP domain name through DNS but instead sends the message to the smart host for delivery. Reasons for using a smart host include

• It provides an entry and an exit point for all Internet messages or messages to a foreign messaging system. This allows you to manage Internet message traffic.

• It provides dial-up solutions. Clients can use a dial-up connection to send messages to and receive messages from the permanently connected SMTP smart host. This reduces connection time because the clients do not need permanent connections to the Exchange server.

You identify the smart host by an FQDN or by an IP address. However, if you use the latter method and then change the IP address, then you need to change that IP address on every virtual server. If you use an IP address, then you must enclose it in square brackets. Exchange checks first for a server name and then for an IP address. The brackets identify a value as an IP address, and Exchange bypasses the DNS lookup. You configure a virtual server to use a smart host by entering the smart host’s identity in the Smart Host box in the virtual server’s Advanced Delivery dialog box.

Configuring an SMTP Virtual Server to Forward Unresolved Messages to a Smart Host

Where an organization has other SMTP messaging systems in addition to Exchange, you can forward all unresolved SMTP messages from Exchange to a smart host. If the smart host cannot resolve the recipient’s name, then the message is returned with an NDR. You configure an SMTP virtual server to forward unresolved messages to a smart host by entering the smart host’s identity in the Forward All Mail With Unresolved Recipients To Host box on the virtual server’s Messages tab.

Configuring an SMTP Virtual Server as a Relay Host

If you configure an SMTP virtual server as an inbound relay host, this gives Exchange Server 2003 smart host capabilities. You can then configure other SMTP servers to use the Exchange virtual server as their smart host and forward all outbound messages to the virtual server. The virtual server then resolves the recipient’s SMTP domain name through DNS and delivers the messages. You configure a virtual server as a relay host by configuring Relay Restrictions on the virtual server’s Access tab.

Configuring an SMTP Virtual Server to Limit the Servers That Can Relay E-Mail Messages

You can prevent unwanted SMTP hosts from using your SMTP host as a relay agent for bulk unsolicited commercial e-mail. You do this by specifying who or what can relay e-mail messages through your organization. You can specify which computers, groups of computers, or domains should be allowed to relay e-mail messages by configuring the SMTP virtual server. You configure the SMTP virtual server to specify which servers can relay e-mail messages through your organization by configuring Relay Restrictions on the virtual server’s Access tab.

Configuring an SMTP Connector to Use a Smart Host

An SMTP connector, by default, uses DNS to resolve the recipient’s SMTP address. You can instead configure the connector to forward all outbound mail to a smart host. You configure an SMTP connector to use a smart host by entering the smart host’s identity in the Forward All Mail Through This Connector To The Following Smart Hosts box on the General tab of the SMTP connector’s Properties dialog box.

Configuring the Domains to Which You Want to Relay Messages

You may want to limit the domains to which you relay messages rather than the domains from which you relay messages. This can be useful when your organization has multiple SMTP messaging systems that operate under different SMTP domain names. You may want your SMTP host to accept messages from any domain but then forward them only to specific domains, such as the other domains in your organization. You can specify the domains to which you want to relay messages on an SMTP connector’s Address Space tab.

Practice: Creating MX Records and Configuring an SMTP Connector

In this practice, you configure DNS to support your Exchange Server 2003 organization and then create and configure an SMTP connector. These are the typical administrative tasks that you carry out when setting up SMTP in an Exchange organization.

Exercise 1: Create MX Records for Your Exchange Server 2003 Servers

In this exercise, you will create MX records for Server01 and Server02. The exercise assumes that both servers are configured as Exchange Server 2003 servers and that the domain controller, Server01, is the primary DNS server (either standard primary or Active Directory Integrated). The MX records will be configured so that an SMTP connection to your organization will first access Server01 and will access Server02 if Server01 is unavailable. After creating the MX records, you use the Command console to verify them.

To create MX records for Server01 and Server02, perform the following steps:

Exercise 2: Create and Configure an SMTP Connector

In this exercise, you create and configure an SMTP connector and specify the default SMTP virtual server on Server02 as the bridgehead server.

Practice: Configuring an SMTP Connector to Use a Relay Host for Outbound SMTP

In this practice, you will configure your SMTP connector to use a relay host for outbound SMTP. To complete this practice, an SMTP connector must exist in your organization. If an SMTP connector does not exist, you must create one by completing Exercise 2 of the previous practice, “Create and Configure an SMTP Connector.”

To configure Exchange to use an SMTP relay host, perform the following steps:

The presence of the word SMARTHOST indicates that the connector is configured correctly. The connector is not truly functional because no SMARTHOST AU computer and no network connectivity exist outside the computers on your test network.